The evolution of wireless communications has resulted in an increase of networks of different technologies and corresponding different air interfaces. As a result, during the course of a single call, a wireless user equipment (UE) may roam among multiple radio access networks (RANs), wherein each such RAN implements a different technology to the other RANs of the multiple RANs, for example, a second generation (2G) and a third generation (3G) circuit switched RAN, such as a GSM (Global System for Mobile communications) network and WCDMA (Wideband Code Division Multiple Access) providing primarily circuit voice service, and a packet data RAN, such as a later generation 3GPP LTE (Third Generation Partnership Project Long Term Evolution) network. As the UE roams among the circuit switched RAN and the packet data RAN providing packet data services, it may be beneficial to system performance to handover the UE between the circuit switched RAN and the packet data RAN for example due to fact that channel conditions associated with the latter RAN may be more favorable than the channel conditions associated with the former RAN. By way of another example, an operator of both a legacy circuit network and a packet data network may desire to move the UE from one such network to the other network for purposes of system load balancing.
In order to offer a successful roaming experience to the user the UE/user needs to register with the new network to receive services that require registration. This registration process is described as Network Attachment. The attach procedure comprise inter alia some signaling relating to identification of the UE and network elements relating to service, security related issues, location update related signaling, bearer(s) allocation for the UE and IP address allocation, for example. FIG. 1 illustrates an E-UTRAN initial attach procedure according to 3GPP specification TS 23.401 V10.5.0 (2011-09) in LTE (E-UTRAN). The procedure illustrated in FIG. 1 is only for background purposes for increasing the understanding, what kind of process is performed, when UE attaches to LTE network.
As already indicated, LTE technology is primarily supporting packet based services only. However, current services in the GSM/WCDMA networks are mainly based on circuit switched (CS) technology. An example of such a service is voice communication. It is noticed that as long as the services based on either packet based or CS technology co-exist, there is need to support the functionality of the service in all networks. One idea to support circuit switched services in LTE network is known as a term CS fallback. CS fallback supports e.g. voice services and traditional CS domain services (e.g. SMS) for LTE and the idea behind the term is to reuse the GSM/WCDMA network resources for implementation of the mentioned services also in LTE. In practice this means that to implement CS fallback functionality in LTE, all participating elements i.e. UE, MME, MSC and E-UTRAN needs to support it.
FIG. 2 illustrates interfaces between different network elements in different networks. In order to enable the CS fallback functionality into the network a new interface SGs is added in LTE architecture. SGs also includes short message service (SMS) functionality comprising SMS without CS fallback. The interface is the reference point between the Mobility Management Entity (MME) in LTE and Mobile Switching Centre server (MSC Server or MSS). SGs interface is used for the mobility management and paging procedures between packet switched and circuit switched domains, and is based on the Gs interface procedures, which is known from GSM/WCDMA.
In view of the current invention it is important to understand that for enabling CS fallback to operate the UE must register on both the LTE and GSM/WCDMA networks to insure that both networks are aware of its presence and location. The UE does not have to perform two registration procedures, because LTE MME performs the registrations into both networks, when the UE attaches to the LTE network. The registration on the GSM/WCDMA network is performed in context of location update over the SGs interface to the MSC in GSM/WCDMA network.
One benefit of CS fallback is that it extends the life of the GSM/WCDMA network by enabling CS services, such as voice, for the LTE. Thus, e.g. telecom operators can get their investments worth, since the existing network infrastructure can be utilized longer. Another benefit is that CS fallback provides complete service and feature transparency with the GSM/WCDMA because the LTE subscriber is redirected to the GSM/WCDMA network for all CS services.
The drawback of the CS fallback solution in general is that it causes heavy signaling between the networks. Additionally, the CS fallback operation may take a while to be established due to signaling and also for Quality of Service measurements if needed. This may be noticed by the user.
One special case in CS fallback is that a user residing in LTE network (UE attached to LTE) wants to start CS based service, e.g. a voice call. In such a case UE sends a service request with the CS fallback indicator to the MME. The request indicates that MME shall establish a CS fallback. MME requests the radio part (eNode B) of LTE redirect the mobile device to the GSM/WCDMA network. In order to achieve the redirection on a radio layer the core network shall be controlled in such a way that it can take the responsibility of the connection management. One important part of this is that there shall be a MSC server dedicated for the UE for CS fallback situation. According to the current practice a MSC server is randomly selected by the serving MME from a pool of MSC servers according to a predefined algorithm (IMSI hash algorithm) when the UE enters to the LTE coverage. This happens e.g. when the UE moves from GSM/WCDMA radio coverage to LTE radio coverage. The problem with this approach is that by selecting a MSC server randomly one needs to deliver subscriber information between different nodes as well as other information like location information. This, in turn, requires signaling between different network nodes as well as may end up unbalanced load between different MSC servers. This is also unnecessary in a sense that when UE is moving from GSM/WCDMA to LTE, it already has a dedicated MSC server in GSM/WCDMA, which comprises all necessary information relating to that specific UE.
The above described random selection of MSC happens also within SGSN based MSC selection due to the fact that MSC Selection algorithm is consistent between SGSNs and MMEs for so called combined registrations over Gs and SGs interfaces. However, when a SGSN or a MME performs a MSC selection there is no consistency with a previous selection made for a UE that was registered via GERAN or RAN access. The inconsistency leads to signaling traffic and thus to unnecessary load to the networks, as already indicated.
More specifically, the root cause of the mismatch is that the selection that is performed via RAN and GERAN uses TMSI, as the NRI within the TMSI is the basis for the MSC Server Selection (in case of RAN, the UE masks the relevant bits in the TMSI to construct the Intra Domain NAS Node Selector (IDNNS), and in the case of GERAN the BSC uses the TMSI itself), but for combined attach the “IMSI hash” is the basis for MSC Server selection.
At least currently, LTE radio coverage is often limited which causes the CS fallback (CSFB) User Equipment to register to a Public Land Mobile Network (PLMN) via GERAN. A typical case where location registration will be performed using Location Updating, an MSC Server will be selected, and the MSC Server will allocate a TMSI with an NRI identifying the selected MSC Server. The NRI is subsequently re-used to identify the MSC Server, and the same NRI is used at TMSI re-allocation, as long as the UE stays in the MSC Pool area. As long TMSI based Location Updating is used the same MSC Server is kept.
Considering that TMSI are allocated by different PLMNs and that in some cases the NRIs will match Core Network nodes between networks and sometimes will be subject to load balancing between the Core nodes, the UEs in the Core Network will be distributed over the MSC Servers in the pool not based on IMSI but on TMSI, even as historically there has to have been an MSC selection performed using IMSI of the USIM.
In the case where the UE is CS fallback capable and detects LTE radio coverage it will perform combined EPS/IMSI attach or combined tracking area updating procedures, and the MME will select a MSC Server for the UE. The same will apply if the UE changes Radio Access Technology where the new RAT offers NMO=1 (Network Mode of Operation), and the old RAT offers a different NMO. In general, NMO is used to indicate if the registration of the UE to the MSC and SGSM is combined (NMO=1) or independent (NMO=2). In NMO=1 the SGSN selects the MSC Server with IMSI hash function.
Subsequent to the MME or SGSN selecting a new MSC Server for the User Equipment, the MSC Server does not change again as long as the UE doesn't change pool areas or re-selects PLMN, as the TMSI and NRI is allocated by the new MSC Server (barring load rebalancing).
Roaming CS fallback subscribers will cause MSC re-selection in the Visited Public Land Mobile Network (VPLMN) to be performed more frequently as those UEs are subject to performing PLMN re-selection. Previously roaming subscribers returning to the Home Public Land Mobile Network (HPLMN) will be allocated to the same MSC Server as previously if the NRI within the TMSI has not been changed by the remote network, but to a new MSC Server in other cases. For those UEs, an additional change of MSC Server will occur when the CS fallback User Equipment enters LTE coverage.
The change of MSC Server in the combined registration case is sub-optimal, and in case of network disturbances or overload, it may delay the recovery of the network. The case where the complete PS domain or EPS is unavailable for a period of time, may lead to further instability in the CS domain when the PS domain or EPS recovers, due to extra signaling load for inter-MSC mobility.
However, the current 3GPP specification TS 23.236 V9.0.0 does not offer a way to select MSC for CS fallback purposes. More precisely, there is no way to deliver information on the serving node between different networks for such a purpose that the new network may need that information in certain situations when offering service to the UE.